<html>
<head><meta charset="utf-8"><title>Splitting up `std::sync` · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html">Splitting up `std::sync`</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="208461860"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208461860" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208461860">(Aug 30 2020 at 00:55)</a>:</h4>
<p>I’ve started looking at refactoring the <code>sync</code> module into new top-level ones as a chance to remove poisoning, shed some baggage, make <code>Arc</code> easier to find: <a href="https://gist.github.com/KodrAus/095cc49d00b22a66fd742bd219b16663">https://gist.github.com/KodrAus/095cc49d00b22a66fd742bd219b16663</a></p>
<p>I’ve got a branch in progress to see what the churn would look like for some big projects out there, but it’ll probably be on the backburner for a while. It might be nice to see if we’ve got appetite for shifting to a new structure for 2021 :slight_smile: </p>
<p>The shape of the new modules and what not to bring over is just a strawman as a starting point. Does anybody have any other wishlist items for <code>sync</code>?</p>



<a name="208462560"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462560" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462560">(Aug 30 2020 at 01:18)</a>:</h4>
<p>huge +1 on doing this!</p>



<a name="208462564"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462564" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462564">(Aug 30 2020 at 01:18)</a>:</h4>
<p>Putting Barrier in std::mutex is a bit strange</p>



<a name="208462571"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462571" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462571">(Aug 30 2020 at 01:19)</a>:</h4>
<p>maybe there's not a clearly good place to stick it though?</p>



<a name="208462696"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462696" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462696">(Aug 30 2020 at 01:22)</a>:</h4>
<p>Yeh, I wasn’t sure where it might belong so ended up stuffing it in <code>mutex</code> just because it’s built on <code>Mutex</code> and <code>Condvar</code></p>



<a name="208462707"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462707" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462707">(Aug 30 2020 at 01:23)</a>:</h4>
<p>honestly we could think about not moving it</p>



<a name="208462711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208462711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208462711">(Aug 30 2020 at 01:23)</a>:</h4>
<p>it's a much more obscure synchronization primitive than mutex/condvar/rwlock</p>



<a name="208463173"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208463173" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208463173">(Aug 30 2020 at 01:39)</a>:</h4>
<p>That sounds good. It looks like its pretty small and I haven’t noticed any usages of it in the compiler yet so will try leaving it deprecated</p>



<a name="208464239"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208464239" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208464239">(Aug 30 2020 at 02:12)</a>:</h4>
<p>I don't think I've ever used it outside benchmark code - maybe worth doing some GitHub searching though, as at least tokio replicated an async version</p>



<a name="208478252"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208478252" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208478252">(Aug 30 2020 at 10:18)</a>:</h4>
<p>I would re-iterate that I don't think <code>mpsc</code> should be deprecated without a replacement. The existence of better implementations isn't enough to warrant deprecation, <code>mpsc</code> is still useful enough on its own. It should be pointed out that there is no stable 1.0.0 alternative to <code>mpsc</code>. <code>chan</code> is deprecated, <code>crossbeam-channel</code> and <code>flume</code> are still <code>0.x</code>. Which makes them all unsuitable for learning materials, because you don't want unstable APIs in tutorials and books about synchronisation primitives. I don't think people will see the removal of this functionality as an improvement to the standard library.</p>
<p>That aside I think the deprecation of the <code>sync</code> module is significant enough that the deprecation lint should be across an edition, even if the new modules are stable much earlier. I think  just the amount of warnings this will trigger alone should put it behind an edition, so that people are opting into seeing that warning.</p>



<a name="208478380"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208478380" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> isHavvy <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208478380">(Aug 30 2020 at 10:22)</a>:</h4>
<p>What's stopping crossbeam-cannel from being 1.0?</p>



<a name="208484712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208484712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208484712">(Aug 30 2020 at 13:12)</a>:</h4>
<p><span class="user-mention" data-user-id="296643">@isHavvy</span> You’d have to ask the maintainers, I’m more pointing out that right now a advertised stable alternative doesn’t really exist right now</p>



<a name="208492676"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208492676" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208492676">(Aug 30 2020 at 16:32)</a>:</h4>
<p>I believe the author of flume is currently working on proposing a change to the standard library that would use flume as the implementation of mpsc. That would address some correctness issues, and provide better performance.</p>



<a name="208492684"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208492684" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208492684">(Aug 30 2020 at 16:33)</a>:</h4>
<p>The correctness issues are, I believe, why people would like to deprecate it.</p>



<a name="208493802"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208493802" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208493802">(Aug 30 2020 at 16:53)</a>:</h4>
<p>Performance and correctness issues aside I think the teaching usecase is a good motivation, but still don’t feel it’s compelling enough to keep mpsc on its own as it is. It’s not complete (it’s just mpsc, no mpmc or oneshots), and it’s not futures aware either. Not having stable alternatives is really just a point in time issue. So I think if we want channels in the standard library going forward then they should be re-examined entirely</p>



<a name="208494466"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494466" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494466">(Aug 30 2020 at 17:05)</a>:</h4>
<p>But by splitting up the <code>sync</code> module we do at least have a good chance to re-examine things!</p>



<a name="208494556"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494556" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494556">(Aug 30 2020 at 17:07)</a>:</h4>
<p>If we do want to bring channels forward then I think they should be mpmc</p>



<a name="208494620"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494620" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494620">(Aug 30 2020 at 17:09)</a>:</h4>
<p>Yeah, I think I agree with all of that, I think it would be good to include that motivation as well motivation for anything else that won't make the transition in the proposal.</p>



<a name="208494788"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494788" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494788">(Aug 30 2020 at 17:13)</a>:</h4>
<p>One of the goals of just picking a standpoint in the RFC is to invite conversation like this to see what people care about <span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span></p>



<a name="208494851"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494851" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494851">(Aug 30 2020 at 17:14)</a>:</h4>
<p>I wonder how disruptive it would be to make <code>flume</code> receivers clonable <span aria-label="thinking" class="emoji emoji-1f914" role="img" title="thinking">:thinking:</span></p>



<a name="208494869"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208494869" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208494869">(Aug 30 2020 at 17:15)</a>:</h4>
<p>It looks like quite a nice implementation</p>



<a name="208502135"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208502135" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lukas Kalbertodt <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208502135">(Aug 30 2020 at 20:11)</a>:</h4>
<p>The ability to make breaking changes in a new module makes sense to me. But FWIW: I quite like the larger <code>sync</code> module with a couple of different but somewhat related functionality (another example: <code>fs</code>). In fact, I rather dislike modules like <code>std::option</code>, <code>std::boxed</code>, <code>std::rc</code>, ... -- which basically house a single type. Most external libraries also seem to expose fewer but larger modules, something I would like for <code>std</code> as well. Though... that ship probably has sailed.</p>



<a name="208776005"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208776005" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208776005">(Sep 02 2020 at 03:31)</a>:</h4>
<p>I think <code>std::collections</code> is another one that fits into that category. It has a _collection_ of unrelated collection types (except <code>Vec</code> which gets its own snowflake module) but doesn’t give me the same grab-bag impression as <code>sync</code> <span aria-label="thinking" class="emoji emoji-1f914" role="img" title="thinking">:thinking:</span> Maybe it’s because there’s something more concrete that ties the items in modules like <code>collections</code> and <code>fs</code> together. <code>collections</code> and <code>fs</code> tell you what the items in them are, <code>sync</code> tells you what you’d use the items for</p>



<a name="208776141"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208776141" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208776141">(Sep 02 2020 at 03:35)</a>:</h4>
<p>On the topic of <code>mpsc</code>, I wonder if <span class="user-mention" data-user-id="128448">@stjepang</span> is still interested in the old <code>std::channel</code> proposal from here: <a href="https://stjepang.github.io/2019/03/02/new-channels.html">https://stjepang.github.io/2019/03/02/new-channels.html</a> It would fit very nicely with the goals and proposed layout of deprecating <code>sync</code></p>



<a name="208776336"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/208776336" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#208776336">(Sep 02 2020 at 03:40)</a>:</h4>
<p>As for <code>atomic</code>, <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> demonstrated how <a href="https://github.com/rust-lang/project-safe-transmute/blob/master/rfcs/0000-ext-generic-atomic.md">safer transmute could let us add a useful <code>Atomic&lt;T&gt;</code></a> that I believe would still work nicely with our existing <code>Atomic*</code>-based types.</p>



<a name="209048455"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209048455" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209048455">(Sep 04 2020 at 01:57)</a>:</h4>
<p>Would anybody be interested in a project group to figure out exactly what a new non-poisoning <code>std::mutex</code>, <code>std::rwlock</code> API should look like, how we should lint against the old APIs without causing some kind of syncpocalypse, possibly also considering enough of a <code>std::channel</code> proposal (looks like <code>flume</code> is MPMC and futures-aware now! Which I think solves pretty much every gripe I had with <code>std::sync::mpsc</code>) that it could be added later?</p>



<a name="209050717"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209050717" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209050717">(Sep 04 2020 at 02:58)</a>:</h4>
<p>While I would love to get rid of mutex poisoning (I explicitly refused to implement poisoning in <code>parking_lot</code>), I am very concerned about the API churn for users. These types are widely used in the public APIs of crates and the new <code>Mutex</code> would be a different type from the old one.</p>



<a name="209050851"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209050851" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209050851">(Sep 04 2020 at 03:02)</a>:</h4>
<p>Hmm ok, I was under the assumption that <code>Mutex</code> isn't typically a part of a public API so thought we might be able to get away with not having to unify them</p>



<a name="209052417"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209052417" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209052417">(Sep 04 2020 at 03:45)</a>:</h4>
<p>I'll try find some examples of libraries that use <code>std::sync::Mutex</code> publicly (I personally always try to hide it) to see how it's used that way. Does anybody know of any already?</p>



<a name="209054893"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209054893" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209054893">(Sep 04 2020 at 04:53)</a>:</h4>
<p>I did this once, <a href="https://docs.rs/randomize/1.0.0/randomize/fn.global_gen.html">https://docs.rs/randomize/1.0.0/randomize/fn.global_gen.html</a></p>



<a name="209054954"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209054954" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209054954">(Sep 04 2020 at 04:55)</a>:</h4>
<p>Thanks <span class="user-mention" data-user-id="224471">@Lokathor</span>! Is that gone in the current version of <code>randomize</code>?</p>



<a name="209055249"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209055249" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209055249">(Sep 04 2020 at 05:02)</a>:</h4>
<p>That's the last version with it, yeah. After that I just put a global_gen mechanic into specific projects that needed it (eg: <a href="https://github.com/Lokathor/dice-bot-rs/blob/master/src/global_gen.rs">here</a>).</p>
<p>Not that using a MutexGuard in the public API was confusing or anything, just that a global generator <em>in general</em> is mildly bad PRNG practice because it discourages you from easy save/restore/replay of whatever you're doing randomly.</p>



<a name="209062275"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209062275" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209062275">(Sep 04 2020 at 07:18)</a>:</h4>
<p>Yeh this is a definitely a good example to look at!</p>



<a name="209068804"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209068804" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209068804">(Sep 04 2020 at 08:46)</a>:</h4>
<p><span class="user-mention" data-user-id="143274">@Amanieu</span> Could you expand on what you mean API churn in this case? I don’t see right now how not having locking in the API would be significantly more churn than introducing a new Mutex type in the first place.</p>
<p>If the concern is “people have <code>.lock()</code> everywhere in their code and it’s a hassle to remove” , I would go back to that if the <code>std::sync</code> transition was part of an edition,  the “churn” is entirely opt-in and we could have a <code>cargo fix</code> lint for upgrading the Mutex type that changes the import and removes all use of <code>.lock</code>.</p>
<p>Obviously that won’t fix cases like <span class="user-mention" data-user-id="224471">@Lokathor</span>’s where the guard is part of the public API, but it should be sufficient for everyone else.</p>



<a name="209069337"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209069337" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209069337">(Sep 04 2020 at 08:53)</a>:</h4>
<p><span class="user-mention" data-user-id="219696">@XAMPPRocky</span> I think in this case it is those public API usages that <span class="user-mention" data-user-id="143274">@Amanieu</span> is referring to</p>



<a name="209069353"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209069353" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209069353">(Sep 04 2020 at 08:53)</a>:</h4>
<p>But that’s also a good point about <code>.lock()</code></p>



<a name="209086287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209086287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> BurntSushi <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209086287">(Sep 04 2020 at 12:15)</a>:</h4>
<p>i'd also be concerned about churn if we're going to deprecate <code>Mutex</code>. there's a lot of code out there using it. if we were to do that, then i'd strongly prefer that we do it at an edition boundary and it, if possible, make it easy to transition to the new mutex type with <code>cargo fix</code>. (i don't know if we can do that automatically. are there cases where people _want_ poisoning?)</p>
<p>as for channels, i still think we should just deprecate mpsc in std and let people use <a href="http://crates.io">crates.io</a>. i don't really buy the argument that we shouldn't do that because there's no stable alternative. in practice, <code>crossbeam-channel</code> is quite stable.</p>



<a name="209088674"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209088674" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209088674">(Sep 04 2020 at 12:41)</a>:</h4>
<p>If the old Mutex type is deprecated in compiler version <code>1.X</code>, then it shouldn't matter if my crate is set for 2015 or 2018 or 2048. The type is deprecated, no matter the edition.</p>



<a name="209088937"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209088937" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209088937">(Sep 04 2020 at 12:44)</a>:</h4>
<p>we should be able to link deprecations to a given version</p>



<a name="209088960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209088960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209088960">(Sep 04 2020 at 12:44)</a>:</h4>
<p>so we would be able to only deprecate a type in the 2021 edition</p>



<a name="209090644"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209090644" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209090644">(Sep 04 2020 at 13:02)</a>:</h4>
<p>But why is compiler version being linked to edition in this case?</p>



<a name="209090773"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209090773" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209090773">(Sep 04 2020 at 13:03)</a>:</h4>
<p>afaict <span class="user-mention silent" data-user-id="222471">BurntSushi</span> wants to only deprecate in edition N while keeping editions &lt;N as is</p>



<a name="209090794"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209090794" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209090794">(Sep 04 2020 at 13:03)</a>:</h4>
<p>might have missed something here though</p>



<a name="209091612"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209091612" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> BurntSushi <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209091612">(Sep 04 2020 at 13:12)</a>:</h4>
<p>i think it might be nice to tie it to the edition, ya, but mainly what i'm after is churn reduction. churn is most painful when it trickles. it we bundle it with the edition changes and what not, and provide a <code>cargo fix</code>, then we reduce churn because folks can do more things at once.</p>



<a name="209091826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209091826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209091826">(Sep 04 2020 at 13:14)</a>:</h4>
<p>we specifically tell people that edition is not an upgrade they need to make, immediately or ever.</p>



<a name="209092017"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209092017" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209092017">(Sep 04 2020 at 13:16)</a>:</h4>
<p>If there is to be a deprecation, it doesn't make any sense for some old edition to not get the deprecated warning when a newer edition does get the warning in the same compiler.</p>



<a name="209092526"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209092526" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> BurntSushi <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209092526">(Sep 04 2020 at 13:21)</a>:</h4>
<p>again, i said, "i think it might be nice." but you're missing my broader point: i want churn to be reduced by bundling deprecations together. doing it when an edition is released does not require deprecating it for a newer edition and not an older edition. it's just adding the deprecation in the same release that the edition is a part of.</p>
<p>to clarify: 1) strongly feel that churn should be minimized by bundling deprecations and what not together and 2) weakly feel that adding a deprecation for a new edition but not an old edition would be even nicer.</p>



<a name="209092578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209092578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209092578">(Sep 04 2020 at 13:21)</a>:</h4>
<p>I’ve definitely wanted poisoning in the past, but never through <code>Mutex</code>, so was thinking a more lightweight <code>panic::Poison&lt;T&gt;</code> might be worth looking at someday.</p>
<p>There’s definitely a lot to think about. I’m not sure how much <code>Mutex</code> comes up in public API (@Lokathor gave an example before), but we’d want to minimise churn as much as we possibly can. People bet on the stability of the standard library so ending up forking a common type like <code>Mutex</code> should be done really carefully. On the other hand I feel like these kinds of things will continue to come up over the next 5, 10, 15 years, so it would be good to get an idea of how we can keep std both relevant and stable over that time</p>



<a name="209092880"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209092880" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209092880">(Sep 04 2020 at 13:24)</a>:</h4>
<p>I think collections that are generic over allocators is in a bit of a similar boat, isn’t it? Where we have some ideas but no silver bullets?</p>



<a name="209092976"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209092976" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209092976">(Sep 04 2020 at 13:25)</a>:</h4>
<p>I do agree with minimizing churn as a general principal.</p>



<a name="209093144"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209093144" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209093144">(Sep 04 2020 at 13:26)</a>:</h4>
<p><span class="user-mention" data-user-id="204346">@Ashley Mannix</span> last I heard, being generic over your allocator is backwards compatible as a change (older folks who didn't give an allocator get the global allocator as their allocator)</p>



<a name="209093349"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209093349" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209093349">(Sep 04 2020 at 13:28)</a>:</h4>
<p>Ah right <span aria-label="+1" class="emoji emoji-1f44d" role="img" title="+1">:+1:</span> I should try catch up on that <span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span></p>



<a name="209107413"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209107413" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209107413">(Sep 04 2020 at 15:26)</a>:</h4>
<p>I think it's also important to make sure we're not taking too big of a step for too small of a change. As a user I'm less likely to use the new stuff if it's not exciting or meaningfully better than the old API. As part of that it's important to note that the <code>std::sync</code> split can only really happen once. So the design of the new APIs should at least consider what could be done to prevent needing to make a <code>std::mutex2;</code> or other equivalents in five years.</p>



<a name="209145311"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209145311" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209145311">(Sep 04 2020 at 22:06)</a>:</h4>
<p>i've done some experimenting with a profiler and some synthetic benchmarks in the past and (on my machine, an x86_64-apple-darwin, in low contention, etc etc) and checking the thread locals to implement poisoning seemed to dominate mutex lock/unlock time, which surprised me.</p>
<p>i guess this is mostly because of <a href="https://github.com/rust-lang/rust/issues/67056#issuecomment-562925627">https://github.com/rust-lang/rust/issues/67056#issuecomment-562925627</a> maybe?</p>
<p>that said people tend to reach for parking_lot as soon as they have mutex perf issues, which would still be the case even if libstd's mutex didn't have this particular issue.</p>



<a name="209145376"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209145376" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209145376">(Sep 04 2020 at 22:07)</a>:</h4>
<p>idk why you couldn't export a <code>std::mutex::{Mutex, PoisoningMutex}</code>, and then std::sync would have a <code>pub use std::mutex::PoisoningMutex as Mutex;</code></p>



<a name="209145470"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209145470" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209145470">(Sep 04 2020 at 22:09)</a>:</h4>
<p>(i guess i agree that poisoning is a dubious choice but it seems weird to deprectate now, unless you're also going to deprecate <code>UnwindSafe</code> and friends — which, to be fair, i'd be in favor of)</p>



<a name="209147892"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209147892" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209147892">(Sep 04 2020 at 22:52)</a>:</h4>
<p>I feel that poisoned mutexes are a much to niche concept to ideally include in the standard library, but I would be more than happy to reexport as <code>std::mutex::PoisoningMutex</code> as <span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> suggested to ease the transition given that they're already there.</p>



<a name="209148970"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209148970" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209148970">(Sep 04 2020 at 23:10)</a>:</h4>
<p>yeah ideally... but i agree with <span class="user-mention" data-user-id="222471">@BurntSushi</span> that it seems maybe too big/common of an API to just deprecate without an automated fix... unfortunately, it doesn't feel like it's trivial to do automatically.</p>
<p>that is, idk how (e.g) rustfix could handle code that attempts to handle poisoning in any way other than <code>unwrap()</code> (it's not rare to see code that by manually extracting the guard, or <code>map_err</code>-ing it which is kinda dubious imo since it's not exactly an error you can meaningfully handle).</p>
<p>but even worse: the <code>.lock().unwrap()</code> case is tough too: it could be a load-bearing unwrap (and if nothing else, i've relied on poisoning in tests to make sure that a data structure holding a mutex behaved as I intended when the mutex got poisoned).</p>
<p>... and do any of the current rustfix transforms change semantics like this?</p>



<a name="209149053"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209149053" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209149053">(Sep 04 2020 at 23:12)</a>:</h4>
<p>one option might be to just deprecate the usage as <code>std::sync::Mutex</code> (is it possible to just deprecate a reexport without deprecating the type itself?), and ask people who can't easily migrate to explicitly use <code>std::mutex::PoisoningMutex</code> (which could be trivially rustfixed). that is, essentially make it so you are explicitly opting in to the poisoning behavior, and deprecating the poison-by-default.</p>
<p>(anyway i had actually thought i was in the minority in thinking poisoning was bad, so i'm actually pretty thrilled to see this thread)</p>



<a name="209153107"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209153107" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209153107">(Sep 05 2020 at 00:43)</a>:</h4>
<p>(Actually, my <code>global_generator</code> function did "handle" the poisoning... by just ignoring it, which is the correct thing to do in that specific case.)</p>



<a name="209167213"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209167213" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209167213">(Sep 05 2020 at 08:06)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> As I understand rustfix works through lints. So if it’s possible to lint against it should be possible to write a transform for it.</p>



<a name="209171985"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209171985" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209171985">(Sep 05 2020 at 10:33)</a>:</h4>
<p><code>PoisoningMutex</code> is an interesting idea <span aria-label="thinking" class="emoji emoji-1f914" role="img" title="thinking">:thinking:</span> I’d be up for that too to help folks actually depending on poisoning or who are stuck with it in their public API.</p>
<p>The <code>UnwindSafe</code> and <code>RefUnwindSafe</code> panic safety system is a bit of an odd one isn’t it, because it’s coarsely applied (so is opted-out for lots of types, even if they are panic safe), is trivial to work around (by just asserting you’re not bothered), and is off the beaten track compared to concurrency so is often overlooked and doesn’t have a lot of tools to support building panic safe types.</p>
<p>I do actually use it though at the FFI of an embedded codebase without <code>AssertUnwindSafe</code>, which imposes a panic safety constraint throughout the rest of the codebase that has caught oversights, so I do find it valuable.</p>



<a name="209172042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209172042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209172042">(Sep 05 2020 at 10:34)</a>:</h4>
<p>It’s just that <code>Mutex</code> is never the tool I reach for when I need panic safety 🙂</p>



<a name="209174543"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209174543" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209174543">(Sep 05 2020 at 11:52)</a>:</h4>
<p>It might be worth making a post on the blog or internals saying the libs team is trying to find out how people use mutex's poisoning? That would at least take the temperature on what users might feel about that change without having to propose a new API.</p>



<a name="209177583"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209177583" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209177583">(Sep 05 2020 at 13:17)</a>:</h4>
<p>The fact that you seemingly can't declare that <code>&amp;mut MyType</code> is always unwind safe is also an unfortunate situation.</p>



<a name="209192193"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209192193" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209192193">(Sep 05 2020 at 19:24)</a>:</h4>
<p>I would also like to get rid of <code>UnwindSafe</code> personally, but that's a lot easier to do than poisoning: just dropping the bound from <code>catch_unwind</code> should be enough.</p>



<a name="209200953"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209200953" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209200953">(Sep 05 2020 at 23:54)</a>:</h4>
<p>I would love to see a bit more of a retrospective on why it’s not so successful as an auto system. That might be helpful for future efforts to design new ones, since they come up from time to time</p>



<a name="209200968"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209200968" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209200968">(Sep 05 2020 at 23:55)</a>:</h4>
<p><span class="user-mention" data-user-id="219696">@XAMPPRocky</span> Good idea! Maybe a blog post + survey would have the biggest reach? I put a quick call out on Twitter and got some more similar examples to <span class="user-mention" data-user-id="224471">@Lokathor</span>’s public guard</p>



<a name="209201064"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209201064" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209201064">(Sep 05 2020 at 23:58)</a>:</h4>
<p>The unwind safe system?</p>



<a name="209201295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209201295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209201295">(Sep 06 2020 at 00:06)</a>:</h4>
<p>Yeh</p>



<a name="209201721"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209201721" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209201721">(Sep 06 2020 at 00:23)</a>:</h4>
<p>What RFC established it? Without knowing the goals, it's hard to say where things wrong.</p>



<a name="209205079"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205079" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205079">(Sep 06 2020 at 02:23)</a>:</h4>
<p>After a little spelunking this looks like the one: <a href="https://github.com/rust-lang/rfcs/pull/1323">https://github.com/rust-lang/rfcs/pull/1323</a></p>



<a name="209205301"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205301" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205301">(Sep 06 2020 at 02:31)</a>:</h4>
<p>It looks like the bound used to be <code>Send + ‘static</code> for historical reasons, there was a desire to just remove them and stabilize a safe <code>catch_unwind</code> with no bounds (like <span class="user-mention" data-user-id="143274">@Amanieu</span> is suggesting now), but that was pushed back on with concerns that we’d make error management through panics too easy and subvert <code>Result</code>. Since <code>Send + ‘static</code> actually tells you nothing about panic safety a new auto trait was introduced for it, which became <code>UnwindSafe</code>. I think the  <code>RefUnwindSafe</code> trait was introduced later to try fix some issues with smart pointers. Thanks, I think, to <code>?</code> that subversion of <code>Result</code> didn’t happen anyways. So now we’re several years on questioning the relevance of <code>UnwindSafe</code>.</p>



<a name="209205679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205679">(Sep 06 2020 at 02:45)</a>:</h4>
<p>Well, first of all, all unsafe code has to be panic safe. That's just a fact.</p>



<a name="209205790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205790">(Sep 06 2020 at 02:49)</a>:</h4>
<p>Next, <code>&amp;mut T</code> is anti-UnwindSafe by default, for... reasons I don't quite get. I suppose it's something about "well what if the type panic'd in the middle of an operation?", but again all types need to be panic safe at all times. If you are ever temporarily in an inconsistent state that could lead to unsafety you need to make sure that no panics can possibly happen during those moments, or your code is unsound. If the code is just in an inconsistent state where things will maybe act weird without being UB, well avoid that but ultimately "whatever".</p>



<a name="209205836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205836">(Sep 06 2020 at 02:50)</a>:</h4>
<blockquote>
<p>Well, first of all, all unsafe code has to be panic safe. That's just a fact.</p>
</blockquote>
<p>this depends on your definition of panic safety. obviously it still needs to behave soundly in the face of panics, but that's not actually what UnwindSafe/RefUnwindSafe are about at all, which i think is another part of the issue — calling it "safety" is very confusing. you're mention of soundness re: &amp;mut T also conflates this. unwind safety is about correctness, <em>not</em> soundness.</p>



<a name="209205847"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205847" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205847">(Sep 06 2020 at 02:51)</a>:</h4>
<p>Yeah, I'd say even just the naming is part of the problem here.</p>



<a name="209205856"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209205856" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209205856">(Sep 06 2020 at 02:51)</a>:</h4>
<p>2015 was perhaps an era of being less disciplined with terminology, I don't think the same name would be developed today in 2020.</p>



<a name="209206316"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209206316" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209206316">(Sep 06 2020 at 03:07)</a>:</h4>
<blockquote>
<p>I would love to see a bit more of a retrospective on why it’s not so successful as an auto system.</p>
</blockquote>
<p>some issues i've had when working with/writing a lot of code that tried to use UnwindSafe/RefUnwindSafe correctly (specifically the code in <a href="https://github.com/mozilla/application-services/">https://github.com/mozilla/application-services/</a>, since all of it's functions go through something like <a href="https://docs.rs/ffi-support/0.4.2/ffi_support/fn.call_with_result.html">https://docs.rs/ffi-support/0.4.2/ffi_support/fn.call_with_result.html</a> , which requires unwind safety)</p>
<ul>
<li>
<p>the things unwind safety guarantees are confusing, partially because of it's name, as i just mentioned.</p>
</li>
<li>
<p>it's hard to "prove" unwind safety, since it's an assertion about basically every line of the type's implementation where a <code>&amp;mut T</code> (or type with interior mutability) is in scope. in practice everything can panic unless you're extremely careful. (ironically, i think thread safety is easier to prove for the most part... at least for many cases).</p>
</li>
<li>
<p>it's rarely used and kind of obscure, so libraries don't manually implement it for their types that use interior mutability, even if they'd consider issues with it a bug.</p>
</li>
<li>
<p>RefUnwindSafe is very poorly documented, but is required to mark a &amp;T of your type unwind safe if it wouldn't otherwise be (i think? i always had trouble making this work).</p>
</li>
<li>
<p>similarly, nothing exists to make <code>&amp;mut T</code> unwind safe, despite the fact that it's possible for me to write a type where i promise something like: "if a panic is emitted from a function it has that takes a <code>&amp;mut MyType</code>, then it will behave as if the function was not called" (a la c++ exception safe types)</p>
</li>
<li>
<p>catch_unwind is required for soundness at FFI barriers, for example (this is being worked on, sure, but for a long time it has been an issue). additionally, if you plan to <code>resume_unwind</code>, it's not really clear if that makes the AssertUnwindSafe okay. these things mean that it's not really practical to try to require unwind safety.</p>
</li>
<li>
<p>the only other language that worries about this that i know of is C++, despite exceptions being very common in many other languages. it <em>feels</em> like this has something to do with memory or thread safety (because it's almost a rust-specific concept), which is scary. (see also: naming)</p>
</li>
</ul>
<p>i could keep going probably. honestly, it really feels like this was added just to discourage using catch_unwind, not because it actually allows you to reason about the correctness of your code.</p>



<a name="209206375"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209206375" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209206375">(Sep 06 2020 at 03:09)</a>:</h4>
<p>a lot of those are related. i think it's a very wishy-washy notion of safety. the thing is: a type made up of thread safe parts is (barring unsafe code) still thread safe.</p>
<p>a type made up of unwind safe parts isn't necessarily unwind safe, which is why the <code>&amp;mut T</code> restriction exists, but also why it works much less well than the other auto traits</p>



<a name="209206478"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209206478" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209206478">(Sep 06 2020 at 03:13)</a>:</h4>
<blockquote>
<p>catch_unwind is required for soundness at FFI barriers, for example (this is being worked on, sure, but for a long time it has been an issue). additionally, if you plan to resume_unwind, it's not really clear if that makes the AssertUnwindSafe okay. these things mean that it's not really practical to try to require unwind safety.</p>
</blockquote>
<p>+1 to this, I have to use AssertUnwindSafe regardless of the type or unwinding will <em>actually</em> be unsound</p>



<a name="209206479"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209206479" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209206479">(Sep 06 2020 at 03:13)</a>:</h4>
<p>so it's actually <em>adding</em> a roadblock to writing correct code</p>



<a name="209208001"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209208001" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209208001">(Sep 06 2020 at 04:08)</a>:</h4>
<p>I'd like to specifically note that a wrapper type which blindly makes a thing "safe" using a value constructor that's totally unchecked is... a poor example if anyone were to emulate it in their own crate.</p>



<a name="209238827"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209238827" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209238827">(Sep 06 2020 at 19:44)</a>:</h4>
<p>yeah, there are a lot of reasons calling it unwind-safety is dodgy... i'm sympathetic for the decision, since the name (seems like it) was taken from c++'s notion of exception safety which can be used to mean either correctness (like UnwindSafe) or soundness (unlike UnwindSafe).</p>
<p>note: c++ does actually distinguish between the "correctness" and "soundness" aspect some, in that there's a "strong exception-safety guarantee" (correctness under exceptions — the moral equivalent to UnwindSafe), but also a weaker "basic exception-safety guarantee" which is basically just soundness under exceptions. (see <a href="https://www.boost.org/community/exception_safety.html">https://www.boost.org/community/exception_safety.html</a> if you want to read more about this for whatever reason)</p>
<p>that said, imo the concept shouldn't exist in rust. UnwindSafe being mostly equivalent to a subtle and (very) tricky to get right c++ invariant (e.g. strong exception safety) doesn't earn it any points from me.</p>



<a name="209243912"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209243912" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209243912">(Sep 06 2020 at 22:13)</a>:</h4>
<p>there's a bunch of discussion about poisoned mutexes being unnecessary, but about 50% pieces of code that I’ve written where mutex was poisoned code would have been unsound if poisoning was not a thing.</p>



<a name="209245790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209245790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209245790">(Sep 06 2020 at 23:09)</a>:</h4>
<p><span class="user-mention" data-user-id="123586">@nagisa</span> But a user can safely ignore poisoning with <a href="https://doc.rust-lang.org/nightly/std/sync/struct.PoisonError.html#method.into_inner"><code>PoisonError::into_inner</code></a>...</p>



<a name="209246541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246541">(Sep 06 2020 at 23:33)</a>:</h4>
<p><span class="user-mention" data-user-id="123586">@nagisa</span> Oh that’s interesting 🤔 Do have any examples to point to?</p>



<a name="209246588"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246588" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246588">(Sep 06 2020 at 23:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="143274">Amanieu</span> <a href="#narrow/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60/near/209245790">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="123586">nagisa</span> But a user can safely ignore poisoning with <a href="https://doc.rust-lang.org/nightly/std/sync/struct.PoisonError.html#method.into_inner"><code>PoisonError::into_inner</code></a>...</p>
</blockquote>
<p>ugh.</p>



<a name="209246599"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246599" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246599">(Sep 06 2020 at 23:35)</a>:</h4>
<p><span class="user-mention" data-user-id="204346">@Ashley Mannix</span> it was mostly in FFI-using wrappers that temporarily make internal state of the data type inconsistent or invalid.</p>



<a name="209246652"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246652" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246652">(Sep 06 2020 at 23:36)</a>:</h4>
<p>an example of that being having a pointer field pointing to an invalid type while its being reconstructed or something along those lines.</p>



<a name="209246718"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246718" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246718">(Sep 06 2020 at 23:38)</a>:</h4>
<p>but I guess that makes the wrapper itself unsound given <span class="user-mention" data-user-id="143274">@Amanieu</span>'s comment above.</p>



<a name="209246731"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246731" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246731">(Sep 06 2020 at 23:39)</a>:</h4>
<p>I always was just very happy with it exploding in my face loudly and never bothered to check if somebody could willingly __ignore__ it.</p>



<a name="209246747"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246747" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246747">(Sep 06 2020 at 23:39)</a>:</h4>
<p><a href="https://crates.io/crates/antidote">https://crates.io/crates/antidote</a></p>



<a name="209246790"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209246790" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209246790">(Sep 06 2020 at 23:40)</a>:</h4>
<p>To maintain soundness you really need to use drop guards.</p>



<a name="209972304"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209972304" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209972304">(Sep 14 2020 at 07:27)</a>:</h4>
<p>I’ve got a draft post in the HackMD now that introduces poisoning and why we think the way we do it on <code>Mutex</code> and <code>RwLock</code> is worth trying to fix. Any feedback or edits would be much appreciated! <a href="https://hackmd.io/icmi6sjlRcKkL9T49iQiDg">https://hackmd.io/icmi6sjlRcKkL9T49iQiDg</a></p>



<a name="209972397"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209972397" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209972397">(Sep 14 2020 at 07:28)</a>:</h4>
<p>cc <span class="user-mention" data-user-id="116122">@simulacrum</span> <span class="user-mention" data-user-id="323697">@Tim McNamara</span></p>



<a name="209975080"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/209975080" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> XAMPPRocky <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#209975080">(Sep 14 2020 at 08:03)</a>:</h4>
<p><span class="user-mention" data-user-id="204346">@Ashley Mannix</span> Great write up, I think it explains the context and motivation for this change effectively.</p>



<a name="210071515"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210071515" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210071515">(Sep 14 2020 at 22:42)</a>:</h4>
<p>Sorry to intervene in this thread, I am no libs-team member, just a random contributor but I do use rust everyday at work and use synchronization primitives from time to time. I've read the HackMD document and personally I think it would be great to explain (or point to proper documentation in other crates) what are the options we have for what happens when a panic occurs using a non poisoning Mutex.</p>



<a name="210073396"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210073396" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210073396">(Sep 14 2020 at 23:06)</a>:</h4>
<p>I <em>think</em> that, assuming you unwind, the MutexLock drops as normal during the unwind, and then the Mutex can just be used later on without any weirdness if you catch the unwind and continue.</p>



<a name="210074508"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210074508" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210074508">(Sep 14 2020 at 23:23)</a>:</h4>
<p>That's also my understanding but it might not be that obvious to everyone. Just explaining that might be good enough.</p>



<a name="210074988"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210074988" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210074988">(Sep 14 2020 at 23:28)</a>:</h4>
<p>And explaining that might also be used as an example for why poisoning Mutex is sometime not that useful: if you call <code>lock().unwrap()</code> unconditionally, then most of the time, you could be using a non poisoning Mutex and get the "same" behavior, being that the panic is forwarded passed the Mutex boundary. One of the difference being what thread gets unwinded</p>



<a name="210075535"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210075535" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210075535">(Sep 14 2020 at 23:35)</a>:</h4>
<p><code>.lock().unwrap()</code> <em>does</em> have a difference when using poisoning or not though.</p>
<p>If the mutex has poisoning and there was a panic during a lock, now you hit the Err and now you're going to panic too.</p>
<p>If the mutex doesn't have poisoning and there was a panic during a lock, you get whatever was leftover in the mutex when the unwind dropped that lock.</p>



<a name="210075760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210075760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210075760">(Sep 14 2020 at 23:38)</a>:</h4>
<p>Sure but from different code i've seen most people "just" want to forward the panic passed the Mutex boundary, wether it's from the thread that panic itself, or later on from a thread that tries to lock it again does not seem to matter much.</p>



<a name="210075818"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210075818" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210075818">(Sep 14 2020 at 23:39)</a>:</h4>
<p>Then they would absolutely need to use the Poisoning version, and a non-Poisoning version would not be correct for their use case.</p>



<a name="210075837"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210075837" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210075837">(Sep 14 2020 at 23:39)</a>:</h4>
<p>Well, not if they just want to terminate the program right?</p>



<a name="210075975"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210075975" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210075975">(Sep 14 2020 at 23:42)</a>:</h4>
<p>If, for example, you have a main thread an a side thread, and they share a value through a mutex, and the <em>side thread</em> panics while holding the lock, it would die, but the main thread would not.</p>
<p>Now the main thread goes to lock: if it's a non-poisoning mutex the main thread will acquire the lock and the main thread will continue with life, possibly totally oblivious to the fact that the side thread is dead.</p>



<a name="210076351"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210076351" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> marmeladema <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210076351">(Sep 14 2020 at 23:46)</a>:</h4>
<p>Ok I see what you mean. I was mistakenly using the assumptions that the main thread would detect the panic in the thread and terminates too.</p>



<a name="210206385"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210206385" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210206385">(Sep 15 2020 at 23:51)</a>:</h4>
<p><span class="user-mention" data-user-id="281572">@marmeladema</span> Thanks for the suggestion! We should note that when a panic unwinds through a non-poisoning lock it typically just unlocks normally and leaves the lock ready for the next consumer</p>



<a name="210206774"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210206774" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210206774">(Sep 15 2020 at 23:55)</a>:</h4>
<p>Should we also say something about <code>Once</code>? It has its own poisoning implementation but is a bit different to <code>Mutex</code> and <code>RwLock</code>. If <code>Mutex</code>'s API was consistent with <code>Once</code>'s it would be:</p>
<ul>
<li><code>.lock()</code> always returns a guard or panics if the <code>Mutex</code> is poisoned (just like if you always called <code>.lock().unwrap()</code></li>
<li><code>.lock_force()</code> always returns a guard and ignores poisoning</li>
</ul>



<a name="210480679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210480679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210480679">(Sep 18 2020 at 05:42)</a>:</h4>
<p>I've put together a Google Form for the survey: <a href="https://docs.google.com/forms/d/e/1FAIpQLSehk-GkwoCag_w3YfXDfgeANulR0h5m2d3EzUMQaiY1vRfIEw/viewform">https://docs.google.com/forms/d/e/1FAIpQLSehk-GkwoCag_w3YfXDfgeANulR0h5m2d3EzUMQaiY1vRfIEw/viewform</a></p>
<p>How does that look to everybody? You technically can submit responses already, but I'll delete any that come through before we do the post <span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span> </p>
<p>Should I add some notes on how long we want to run the survey for? And who the results will be shared with?</p>



<a name="210512454"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210512454" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210512454">(Sep 18 2020 at 12:41)</a>:</h4>
<p>I'd also be interested in collecting examples of when poisoning actively protected a program after a bug-induced panic (i.e. the process was better off with the poisoned lock than it would have been without it)</p>



<a name="210513934"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210513934" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210513934">(Sep 18 2020 at 12:57)</a>:</h4>
<p>That’s a good idea!</p>



<a name="210540351"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210540351" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210540351">(Sep 18 2020 at 16:02)</a>:</h4>
<p>It might be a good idea to ask if people use poisoning locks for anything other than <code>m.lock().unwrap()</code> (could phrase that better) since I do intentionally use poisoning locks but always only for propagating panics, not for recovering after a panic.</p>



<a name="210600250"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210600250" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Ashley Mannix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210600250">(Sep 19 2020 at 06:26)</a>:</h4>
<p>I’ll reword it a bit so it’s clear that we’re asking whether you do <code>m.lock().unwrap()</code> “on purpose”</p>



<a name="210631590"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Splitting%20up%20%60std%3A%3Async%60/near/210631590" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Samuel Harrington <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Splitting.20up.20.60std.3A.3Async.60.html#210631590">(Sep 19 2020 at 19:36)</a>:</h4>
<p>I think the question at the start of the survey would be better as 2 questions: </p>
<ul>
<li>Do you use std mutexes?</li>
<li>Do you use non-std mutexes?</li>
</ul>
<p>If the respondent uses both std mutexes and non-std mutexes, then they would answer both sections.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>